Rollback Prepared Transactions Asynchronously During Binlog Crash Recovery - #711
Rollback Prepared Transactions Asynchronously During Binlog Crash Recovery#711SongLibing wants to merge 1 commit into
Conversation
|
Thank you for your pull request and welcome to our community! To contribute, please sign the Oracle Contributor Agreement (OCA).
To sign the OCA, please create an Oracle account and sign the OCA in Oracle's Contributor Agreement Application. When signing the OCA, please provide your GitHub username. After signing the OCA and getting an OCA approval from Oracle, this PR will be automatically updated. If you are an Oracle employee, please make sure that you are a member of the main Oracle GitHub organization, and your membership in this organization is public. |
oracle-contributor-agreement
Bot
added
the
OCA Required
github-actions
Bot
added
MTR Failed
|
Thank you for signing the OCA. |
oracle-contributor-agreement
Bot
added
OCA Verified
e6d0129 to
c85ef66
Compare
c85ef66 to
6d6e94a
Compare
|
Thank you SongLibing for this. We've uncovered that internally in Oracle this same issue and solution(s) have been discovered a couple years ago, discussed and documented, but not prioritized. We've made https://bugs.mysql.com/bug.php?id=114053 public so that it may benefit the review of this PR. The review will take its time, we will probably want both a member from replication team as well as InnoDB team to look at this and this is obviously very critical part of the database, so they will take their time. Other than that everything seems to be in order now, oca signed and tests green. |
6d6e94a to
5be807a
Compare
github-actions
Bot
added
Build
23d5eee to
23b5313
Compare
Crash Recovery Description =========== Binary log crash recovery resolves internal transactions that were prepared in a storage engine before the server stopped. If the binary log does not contain the transaction's commit decision (Xid_log_event), the transaction must be rolled back. Historically, the server invokes `rollback_by_xid()` in the startup thread and waits for the complete rollback. Undoing a large transaction row-by-row can therefore keep the server unavailable for hours. This change adds an optional recovery-specific storage-engine callback to perform a fast rollback handoff. InnoDB uses it to durably change the state of a prepared DML transaction back to active. The existing InnoDB recovery rollback thread then does the expensive row-by-row undo work in the background while server startup continues. The final transaction outcome does not change. detail: design/server/100-async-rollback-during-binlog-recovery.md
23b5313 to
a2ea313
Compare
2 participants
Problem:
Binlog recovery can block server startup for a long time when it must roll back a large prepared internal XA transaction. The rollback runs synchronously before the server becomes available.
Solution:
Add an optional storage engine callback, recover_rollback_by_xid, for recovery-time rollback. During binlog recovery, InnoDB uses the callback to persistently convert a recovered prepared DML transaction back to ACTIVE state. The background recovery rollback thread then performs the expensive undo work asynchronously. DDL transactions still fall back to the normal synchronous rollback_by_xid path.
Add a binlog MTR test that covers prepared DML rollback, background rollback handoff, and repeated-crash safety before the rollback state change is flushed.
Copyright (c) 2026, Oracle and/or its affiliates.
What does this change do?
mysql/mysql-community#100
How was it tested?
mysql-test/scripts/ci/mtr.shpasses locallyContributor checklist
scripts/ci/format.sh)AI assistance
If AI assistance was used, describe the tool(s) and extent of use: codex, only merge code from AliSQL to trunk.
Areas touched
replication, innodb